home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Amiga Plus 2000 #5
/
Amiga Plus CD - 2000 - No. 5.iso
/
Tools
/
Misc
/
EZHome
/
Readme
< prev
next >
Wrap
Text File
|
2000-01-01
|
7KB
|
140 lines
July 18th, 2000, the Heskett Ranchette in WV, USA
With further updates as I swat ever smaller bugs in the 1.00 release
Last update July 18, 2000 Gene Heskett
This is the version 1.00i upgrade package for registered users prepared by
Gene Heskett, half of the EzSoft team. Unforch, Jim's machine seems to
have passed on, so I'm the remaining 'it' for EzSoft :)
cd to your 'EzHome:' assign and unpack this right over the original
install, or rename the files EzHome and EzHomePrefs by appending their
version numbers to the name if you'd like to save them for posterity,
whatever that is.
1. You will now find that the housecodes that didn't work, now do. You'll
also note that the housecode in the gui display is actually updated from
the status data fed back to the gui from the daemon, so that it will show
properly in the gui even if you grab a shell and give the daemon a command
like "rx 'address ezhome sethouse p'", even if you do it while the gui
isn't running. The initial status update the gui asks for will update it
to the current housecode in both displays.
One thing that may not be readily apparent is that the RealTime page, the
front page if you will, can issue commands to other housecodes besides the
one the prefs page is set at. Only by changing it from a cli, or from the
prefs page, is the cm-11a's actual house monitor updated. I update the
RealTime page too, unforch without updateing the button labels in the left
column. That might be in V1.01 if its easily done. The GUI is another
animal entirely :)
2. You will now find your registered name is displayed by the about
requester, the 'house' icon in the upper right corner of the gui being the
button for that.
3. Somewhere along the line, the daemons quick mode was commented out, so
that probably doesn't work. I've never run it that way myself, and it is
designed to be a background daemon waiting to do your bidding anyway.
4. Late fixes to the daemon include the detection of the word 'RUNIT' in
the descriptor portion of the EZHome:prefs/Action.prefs file
While testing it here, I kept getting guru's from 'SPEAK' because
it was trying to be a whole committee meeting with several copies
of talkingclock trying to get to it at the same time. So a new
'VARIABLE' has been added. If the function IS safe to run multiple
copies of itself, then add the keyword 'RUNIT' to the end of the
description and resave the prefs. If it is not safe to run
concurrant copies of the command, the daemon will now WAIT for
the command to execute before continueing. As some commands might
be lengthy scripts, thereby holding up the daemon till they return,
it is probably better to have the script set a small file in RAM:
to indicate to other copies that may be launched that it is already
running, and if it finds it, before it sets it, it should exit.
The original copy of course needs to delete that tallying file as
the last thing it does before quiting. This doesn't actually
require a lot of code to do. Here is one way to do it.
-----------------------
/* AREXX requies the FIRST line to be a comment line */
/* ARexx script to prevent more than one copy of 'unique_name' from being run */
SIGNAL ON BREAK_C /* make it breakable via ctl-c */
options results
mytest = 1 /* set this to 0 to run your script or program instead of my test delays */
runfile = 'ram:unique_name' /* change to suit human readability */
/* most arexx stuff needs this, make sure its already in memory */
IF ~SHOW('L','rexxsupport.library') THEN CALL ADDLIB('rexxsupport.library', 0, -30)
IF ~SHOW('L','rexxdossupport.library') THEN CALL ADDLIB('rexxdossupport.library', 0, -30)
IF ~EXISTS(runfile) THEN DO
ADDRESS COMMAND 'date >'runfile
IF mytest = 1 THEN DO
CALL DELAY(1500) /* 30 secs to test the rest of the routine */
END
ELSE DO
/* "include" your original arexx script here with your favorite editor
one could also run something else with the usual
ADDRESS COMMAND name_of_program (or shell script) to be run here
*/
END
END
BREAK_C: /* fall thru to clean house, or if broke with ctl-c */
ADDRESS COMMAND 'delete >NIL: 'runfile
EXIT 0 /* all done, quit this instance W/O error */
-----------------------
4a! The most recent change is to treat something being sent to itself as
a RUNIT item regardless of whats in the prefs file comment. Prevents
lockups in the situation where it is sending a message to itself,
but waits forever at the send point for a receipt it will never get,
being stuck at the 'send it' point waiting. This, as of July 2, has
been fine tuned a bit as I found it was arbitrarily running anything
located in the EzHome: assign, not what I wanted at all. So it now
checks the string comparisons against the full 'ADDRESS EZHOME',
requireing a return of greater than 4 before that behaviour is
triggered. Since a normal commandline string also is prefaced
with 'RX "ADDRESS EZHOME"' which returns a 5 when queried with
POS(search,target) this seems pretty safe. Version is now 1.00h.
4b! A couple of fixes for a runaway send, and it now logs in 3 places,
once for an arexx received command, once for a powerline received
command, and again for a powerline sent command. If the logfile
level is 2, it also logs Action.prefs about to be done as of V1.00i.
4c! I've noted that we don't really specify the contents of the file
"EZHome.prefs", so here is my current one with added comments:
comment line in file content of fileline
Location to save logfile to 1 sd0:ezhlog.txt
Serial devices name 2 duart.device
Serial device unit number 3 0
Default house code number 4 6
Logfile detail level 5 2
Just 5 lines, located obviously in the EZHome:prefs directory.
Line 1-3 are self-explanatory. Here I can run it on the seriel.device
just as easily, but I had this spare port on my Multiface III since my
networking uses an ethernet card to my linux box, which still auto-dials
when this machine wants online :-)
Line 4 is the housecode as decoded, that 6 equals house A.
Line 5 if = 1 will cause what it has done to be logged, if 2 will cause
it to also log what Action.prefs it is *about* to do. This is for
V1.00i and greater only, a troubleshooting aid. The extra logging will
slow it down because it will be between the event coming in and the
actual performance of the Action.prefs event.
4d! Un-mentioned are troubleshooting outputs obtainable when ezecuting
the daemon from a shell. 'ezhome -v' will get you a LOT of output as
it sort of self traces its execution, including the line number in
the source code, please report these if possible.
A late addition is a second 'ezhome -s' option which will trace only
the powerline reception and handling code, and will, when it does a
readprefs, also output the Ezhome.prefs lines, but only in that code
built *after* 07-15-2k will the prefs be read back, thats why it
grew about 80 bytes.
5. Beat on it and give me feedback please, addressing flowers and flames
to <gene_heskett@iolinc.net>